\subsection{Aclaraciones}
En esta sección vamos a detallar algunas salvedades que consideramos sumamente importantes para la correcta interpretación de los modelos realizados.\\
Iremos detallandando ciertas consideraciones que tuvimos en cuenta al realizar este trabajo en su totalidad como así también cada modelo particular. Debido a esto, como primera medida enunciaremos aquellas decisiones a nivel general sobre la interpretación del enunciado y las consiguientes decisiones tomadas. Luego, presentaremos las medidas que tomamos para cada modelo particular, comentando por qué fue que elegimos una determinada opción y no otra.\\

\subsubsection{Nuestro diagrama de contexto}

\begin{figure}[!ht]
	\begin{center}
		\includegraphics[scale=0.5]{imagenes/diagramas/DiagramaContexto.png}
	\end{center}
	\caption{El diagrama de contexto en el cual nos basamos para realizar el TP} 
\end{figure}

\clearpage

\subsubsection{Interpretaciones Generales}
\begin{itemize}
\item	Al momento de la verificar que el stock de un ingrediente se encuentre por debajo del límite establecido, el sistema observara todos los valores de la clase conceptual Stock de la siguiente forma: se informará baja de stock cuando limiteMinimo $>$ cantidadDisponible + cantidadReservado + cantidadComprada
\end{itemize}

\subsubsection{Modelo Operacional}
\begin{itemize}
\item Más allá de que el sistema se encargue del cálculo del límite tolerable para un determinado ingrediente, nos parecio correcto darle la opción al Repositor de cambiar el mínimo tolerable de un ingrediente si así lo deseara. Esto no sólo por una cuestión de flexibilidad, sino para poder ajustarlo en base a la situación en la que se encuentre la sucursal respecto de las ventanas, como así también por diversos factores por lo cual éste considere que variar esta cota sea relevante.
En el presente informe \textbf{nivel mínimo tolerable}, \textbf{límite tolerable} y \textbf{límite mínimo} se usarán de manera indiferente. Siempre que querramos referirnos al mínimo valor que debe tener el stock de un determinado ingrediente usaremos una de las tres expresiones mencionadas anteriormente.
\end{itemize}

\subsubsection{Modelo conceptual}
\begin{itemize}
  \item	Consideramos que no es necesario llevar un registro de los clientes debido a que en ningún punto se hace mención a tener un registro de los mismos. Al cliente se le entregará un ticket con el número de su pedido, y este sólo participa como vínculo informativo, pero que no es relevante para la construcción del sistema.

  \item Siguiendo la base del item anterior, decidimos que tampoco es relevante para el sistema tener información sobre los empleados de las sucursales. Más allá de que algunos iteractuen directamente con el sistema, no es un aspecto que este modelo deba considerar. Para el sistema es indiferente quién ingresa el pedido (quizá el encargado está ocupado, y otra persona puede relevarlo para ingresar un nuevo pedido por ejemplo, y esto, para el sistema, es transparente).

  \item Consideramos que debe existir una clase conceptual Menú, más allá de que las sucursales se encuentren sincronizadas todo el tiempo y que este sea general a todos.
  %Completar porque era así....ver mail de Guido
\end{itemize}

\subsubsection{Modelos de Actividad y Comportamiento}

\begin{itemize}
  \item	Aunque en la presentación de los escenarios, se plantea una posible superposición a la hora de ingresar cambios al menú por parte de dos sucursales en un mismo instante de tiempo, creemos que esto no podrá ocurrir debido a que en la solución elegida esto se resuelve usando un esquema por turnos de tipo \textbf{ROUND-ROBIN} con lo cual nunca van a existir dos sucursales con posibilidad de ingresar algún cambio en un determinado momento.
\end{itemize}
